BookmarksTab was reusing InboxTab's navToActivePath logic, so if the
user had previously visited inbox/notifications, clicking the bookmarks
button would navigate there instead of inbox/bookmarks.

The tab now always navigates directly to getInboxBookmarksPath(),
which also fixes the mobile regression where no navigation occurred
(InboxTab's mobile guard was absent here).

After checkDueReminders fires a bookmark reminder notification, the SW
persists only the remaining (non-due) reminders to its cache — but
useReminderSync would immediately overwrite that cache by pushing the
full list from Matrix account data (which hadn't been updated).

Fix: the SW now posts a { type: 'remindersFired', bookmarkIds } message
to all open window clients after firing. useReminderSync listens for
this message and calls clearBookmarkReminder for each fired ID, updating
account data so the next syncReminders call pushes the correct subset.

…nimal purge tombstone

- sw.ts: include isReminder in the notificationClick postMessage so the
  running app can handle reminder taps correctly without falling through
  to the "no roomId" early return.
- ClientNonUIFeatures.tsx: HandleNotificationClick now opens the
  bookmarks panel (bookmarksPanelAtom) when isReminder is true, instead
  of doing nothing (previously bailed out at the !roomId guard).
- bookmarkRepository.ts: purgeBookmark now writes the minimal tombstone
  { deleted: true, purged: true } instead of spreading the original
  bookmark content. The original room/event metadata no longer lingers
  in account data after a permanent archive deletion.

The bell icon + datetime picker were only wired up in the panel/inbox
variant (features/bookmarks/BookmarksList). The full-page view rendered
via the router (pages/client/bookmarks/BookmarksList) had no reminder
UI at all.  Add useBookmarkReminders + useBookmarkReminderActions to
BookmarkItemRow so the bell icon and inline picker appear there too
when enableBookmarkReminders is enabled.

BookmarksPanel and its associated BookmarksList in features/bookmarks
were never wired into the router or any live component. The full-page
bookmarks view at pages/client/bookmarks/BookmarksList is the only
real implementation.

Also fix HandleNotificationClick: bookmarksPanelAtom never existed, so
reminder notification taps were silently broken. Navigate to the inbox
bookmarks route instead.

- BookmarksTab: show filled bookmark icon when bookmarks exist (not just
  when the panel is selected) — glanceable indicator restored
- useClientConfig: re-export EXPERIMENT_OVERRIDE_PREFIX so consumers can
  import it instead of duplicating the string literal
- ExperimentsPanel: import EXPERIMENT_OVERRIDE_PREFIX from useClientConfig
  instead of re-declaring it locally

…-app reminder routing

- ClientNonUIFeatures: add ReminderBanners component that listens for
  remindersInApp SW messages and shows an in-app banner; wire into
  RemindersFeature alongside ReminderSync
- sw.ts: persist appVisibleAt timestamp so cold SW restarts on iOS/iPad
  can still suppress duplicate OS notifications within 30 s of the app
  being visible; call persistSettings() on setAppVisible so the timestamp
  is written immediately
- sw.ts: in checkDueReminders(), route due reminders as in-app banners
  (remindersInApp postMessage) when a visible tab is open, falling back to
  OS showNotification() otherwise — avoids duplicate alerts on iPad

Two SW fixes for bookmark reminders:

1. Cold-start notification click: the previous code built a /to/:roomId/:eventId
   URL which ToRoomEvent misparses (it expects /to/:userId/:roomId/:eventId).
   Navigate to /inbox/bookmarks/ instead — consistent with the warm-start path
   where HandleNotificationClick already calls navigate(getInboxBookmarksPath()).

2. checkDueReminders: switch from Promise.all to Promise.allSettled so that
   persistReminders() and the remindersFired postMessage always execute, even
   when showNotification() rejects (e.g. notification permission has been
   revoked). Without this, fired reminders stayed in the SW cache and would
   re-fire on every subsequent 60 s interval.

datetime-local inputs expect a local-time value (YYYY-MM-DDTHH:MM).
Using toISOString() produced a UTC timestamp instead, so users in
negative UTC offsets (e.g. EDT UTC-4) would see the stored UTC time
(00:15) rather than the local time they entered (20:15).

- BookmarksTab: show filled bookmark icon when bookmarks exist (not just
  when the panel is selected) — glanceable indicator restored
- useClientConfig: re-export EXPERIMENT_OVERRIDE_PREFIX so consumers can
  import it instead of duplicating the string literal
- ExperimentsPanel: import EXPERIMENT_OVERRIDE_PREFIX from useClientConfig
  instead of re-declaring it locally

… outside tooltip

Two bugs fixed:

1. Reminders only fired on one device
   The SW sent a 'remindersFired' message when it showed an in-app banner,
   which caused the receiving device (whichever had the app open) to delete
   the reminder from Matrix account data. That prevented other devices from
   ever firing their own copy.

   Fix: remove the remindersFired auto-clear entirely. Each device now tracks
   a firedAt timestamp in its own SW cache (sable-reminders-v1). checkDue-
   Reminders skips entries that already have firedAt set, and updateReminders
   preserves firedAt when the same bookmarkId/remindAt pair is re-synced.
   The user dismisses the reminder explicitly via 'Clear Reminder'.

2. 'Clear reminder' / overdue chip didn't update reliably
   clearBookmarkReminder wrote to the server via setAccountData. The local UI
   only updated when the sync loop echoed the change back, which could take
   seconds — making it look like the clear had failed.

   Additionally, the concurrent remindersFired auto-clear + manual clear
   created a read-modify-write race (both read the current list, filter, write
   — the second write would win with stale data).

   Fix: introduce remindersAtom (global Jotai state). useBookmarkReminderActions
   now performs an optimistic atom update before the server write, so the UI
   responds instantly. useReminderSync is the single source of truth when real
   account data arrives.

…types locally

These types were only defined in feat/developer-tools. Since message-bookmarks
uses selectExperimentVariant / useExperimentVariant independently, define the
types directly in useClientConfig.ts and add experiments to ClientConfig.